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Windows 8 Security Overview 


Secure Development 

The development of Windows 8 followed the 
Security Development Lifecycle (SDL) which 
defines best practices for secure software 
design, implementation, and testing. 


Securing the Core 

Windows 8 includes numerous security 
features, such as mitigations, that make it 
difficult and costly for malware authors to 
develop reliable exploits for vulnerabilities. 


Securing the Boot 

Windows 8 includes new protections against 
root and boot kits. UEFI systems prevent 
malware from starting before Windows and 
protects the remainder of the boot process, 
including early launch antimalware software. 


Securing After the Boot 

Windows Defender is shipped with every 
edition of Windows 8 and Internet Explorer's 
Application reputation features have been 
moved into the platform such that users are 
protected regardless of the browser they use. 
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Framing the problem with exploit economics 


Attackers want to 
maximize ROI 
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Gains per use 
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Opportunities to use 
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Cost to acquire vulnerability 




We want to 
minimize ROI 



Cost to weaponize 
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Today we will describe exploit mitigation improvements in Windows 8 
that increase the cost of developing reliable exploits 
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History of exploit mitigations on Windows 


VOID Function(LPCSTR Input) { 
Stack-based CHAR Buffer[256]; 

vulnerability Strcpy (Buffer, Input); 

} 


Non-linear/backward 
overwrites 
(e.g. a[n] = 0) 


GS vl 

( 2002 ) 

GS vl.l 

(2003) 

GS Ml 

(2005) 

GS v3 

( 2010 ) 



SafeSEH 

(2003) 


Linear return 
address 
overwrite 


Linear local 
variable 
overwrite 


Linear 

parameter 

overwrite 


Linear 
SEH record 
overwrite 


Stack-based exploitation 
and mitigation 
techniques 


Control of 
Instruction Pointer 
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History of exploit mitigations on Windows 


Heap-based 

vulnerability 


Coalesce 

unlink 

overwrite 


Safe 

unlinking 

( 2004 ) 


Heap-based exploitation 
and mitigation 
techniques 


VOID Function(LPCSTR Input) { 
PCHAR ^Buffer = malloc(256); 
strcpy(Buffer, Input); 

} 


FreeList[] 

attacks 


Lookaside list 
attacks 


Heap cache 
attacks 


LFH 

FreeEntryOffset 

attack 


Application 
specific data 
overwrites 


Use-after-free/ 
Double free/ 
Dangling pointer 


Vista heap hardening 

( 2006 ) 


Overwrite or 
control a function 
pointer 


Control of 
Instruction Pointer 
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History of exploit mitigations on Windows 


Control of 
Instruction Pointer 


eip=41414141 esp=0023f7dc ebp=0023f808. 
cs=0023 ss=002b ds=002b es=002b fs= 

41414141 ?? ??? 


Execute code 
from stack 


Execute code 
from heap 
(incl. heap spray) 


Execute JIT'd code 
(JIT spray) 


Execute code from a loaded image 


DEP 

( 2004 ) 


IE9JSJIT 

mitigations 

( 2011 ) 


Executing arbitrary code 
after gaining control of EIP 





„ . ^ Return oriented 

Return-into-libc 

, . * , programming 

(many variants) (ROp) 



ASLR 



( 2006 ) 


Predictable 
mappings/info leaks 



Arbitrary code 
execution 
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yv_/V_/V_/V 


The state of memory safety exploits 



Bottom line: we must continue to increase the cost of exploitation for attackers 
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Objectives & focus areas in Windows 8 


Objectives 

Mitigate entire 
classes of 

vulnerabilities 

Break known 
exploitation 
techniques 

Increase 
the cost of 
exploitation in 
key domains 

Code Generation Security 

Address Space Layout Randomization 

Windows Heap 

Windows Kernel 

Default Settings 









Enhanced /GS, range checks, sealed optimization, and virtual table guard 

CODE GENERATION 
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Enhanced /GS 


Enhanced GS stack buffer overrun protection 

- Released with Visual Studio 2010 [ ] 

- Windows 8 is built with this enabled 

GS heuristics now protect more functions 

- Non-pointer arrays and POD structures 

GS optimization removes unnecessary checks 

- Safety proof means no check is needed 

Closes gaps in protection 

- MS04-035, MS06-054, MS07-017 (ANI) 


Range Checks 


• Compiler-inserted array bounds check (via /GS) 



• Completely mitigates certain vulnerabilities 

- CVE-2009-2512, CVE-2010-2555 

• Bounds check insertion is limited to specific scenarios 

- Assignment of NULto a fixed-size stack/global array 


12 










Sealed optimization 


• Optimization for "sealed" C++ types & methods 


class COptionElement sealed : public CElement 
{ 

DECLARE_CLASS_TYPES(COptionElement, CElement) 


• Virtual method calls become direct calls 

Without sealed 



COptionElement *optionElement; 



optionElement->IsEnabled(); 



With sealed 


mov rax,qword ptr [rex] 
call qword ptr [rax+ 920 h] 


call CElement::IsEnabled 


# 


Eliminating indirect calls reduces exploitation attack surface 

- Helps mitigate vulnerabilities like CVE-2011-1996 

- Devirtualized ~4,500 calls in mshtml.dll and ~13,000 in mso.dll 


13 




Virtual Table Guard 

Probabilistic mitigation for vulnerabilities that enable vtable ptr corruption 


IE10 has enabled 
this for a handful of 
key classes in 
mshtml.dll 



CElement::'vftable' 

VirtualMethodl 


VirtualMethod2 


VirtualMethod3 


VirtualMethod4 




vtguard 





mshtml!CElement::Doc: 


63700e70 mov 

63700e72 cmp 
63700e7c jne 

63700e7e call 
63700e84 mov 
63700e87 ret 

call 


eax,dword ptr [ecx] 

[eax+lB8h],offset mshtml!_vtguard 
mshtml!CElement::Doc+0xl8 

dword ptr [eax+OACh] 
eax,dword ptr [eax+OCh] 




63700e88 



Extra entry added to vtable. 
ASLR makes this entry's value 
unknown to the attacker. 


mshtml!_report_gsfallure 


Check added at virtual method call sites. 
If vtable[vtguard_vte] !=vtguard 
then terminate the process. 
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Force ASLR, bottom-up/top-down randomization, and high entropy 

ADDRESS SPACE LAYOUT 
RANDOMIZATION 
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Retrospective: ASLR 


• ASLR was first introduced in Windows Vista 

- Led to a big shift in attacker mentality 

• Attackers now depend on gaps in ASLR 

- EXEs/DLLs not linked with /DYNAMICBASE [ ] 

- Address space spraying (heap/JIT) [ ] 

- Predictable memory regions [ ] 

- Information disclosures [ ] 

• ASLR has been substantially improved in Windows 8 


16 


Force ASLR 


Many exploits depend on non-ASLR DLLs 

Images are not 
randomized unless the 
DYNAMIC_BASE bit is set 

Processes can now force non-ASLR images to be randomized 

- Behaves as if an image's preferred base is not available 

- Bottom-up randomization provides entropy for these images 

Processes must opt-in to receive this behavior 

- Also supported on Windows 7 with KB2639308 installed 


0:000> !dh dirapi 

4B4C111C time date stamp Mon Jan 11 22:05:16 2010 

1000 base of code 

-new- 

68000000 image base 

1000 section alignment 

00001000 size of heap commit 

0 DLL characteristics 

187A80 [ 402F] address [size] of Export Directory 

1869F4 [ C8] address [size] of Import Directory 

19B000 [ 12178] address [size] of Resource Directory 


Outcome: attackers can no longer rely on non-ASLR images 






Bottom-up & top-down randomization 

Windows 7 

• Heaps and stacks are randomized 

• PEBs/TEBs are randomized, but with limited entropy 

• VirtualAlloc and MapViewOfFile are not randomized 

• Predictable memory regions can exist as a result 


Windows 8 

• All bottom-up/top-down allocations are randomized 

• Accomplished by biasing start address of allocations 

• PEBs/TEBs now receive much more entropy 

• Both are opt-in (EXE must be dynamicbase) 

Outcome: predictable memory regions have been eliminated 


Top-down allocations 

(PEBs, TEBs, MEM_TOP_DOWN) 



Bottom-up allocations 

(stacks, heaps, mapped files, VirtualAlloc, etc) 
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High entropy ASLR for 64-bit processes 

ASLR in Windows 8 takes advantage of the large address space (8TB) of 64-bit processes 



High entropy 


bottom-up 


randomization 


High entropy 
top-down 
randomization 


High entropy 


image 


randomization 


• 1TB of variance in bottom-up start address 

• Breaks traditional address space spraying (heap/JIT) 

• Processes must opt-in to receive this behavior 


8 GB of variance in top-down start address 
Automatically enabled if top-down randomization is on 


Images based above 4 GB receive more entropy 
All system images have been moved above 4 GB 


Outcome: probability of guessing an address is decreased and 
disclosures of memory addresses must include more than the low 32 bits 
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ASLR entropy improvements 


Entropy (in bits) by region 

Windows 7 

Windows 8 

32-bit 

64-bit 

32-bit 

64-bit 

64-bit 

(HE) 

Bottom-up allocations (opt-in) 

0 

0 

8 

8 

24 

Stacks 

14 

14 

17 

17 

33 

Heaps 

5 

5 

8 

8 

24 

Top-down allocations (opt-in) 

0 

0 

8 

17 

17 

PEBs/TEBs 

4 

4 

8 

17 

17 

EXE images 

8 

8 

8 

17* 

17* 

DLL images 

8 

8 

8 

19* 

19* 

Non-ASLR DLL images (opt-in) 

0 

0 

8 

8 

_ 

24 


* 64-bit DLLs based below 
4GB receive 14 bits, EXEs 
below 4GB receive 8 bits 


ASLR entropy is the same for both 
32-bit and 64-bit processes 
on Windows 7 


64-bit processes receive much more 
entropy on Windows 8, especially with 
high entropy (HE) enabled 


20 



















Removal of information disclosure vectors 


• Information disclosures can be used to bypass ASLR 


• Disclosure via an arbitrary read is now less reliable 

- Predictable mappings have been eliminated 


• SharedUserData is still predictable, but less useful 

- Image pointers have been removed, breaking known techniques [4,6] 


0:000> u ntdll!NtWriteVirtualMemory L6 
ntdll!NtWriteVirtualMemory: 

6a214724 b802000000 mov eax,2 

6a214729 e803000000 call ntdll!NtWriteVirtualMemory+Oxd 

(6a214731) 

6a21472e c21400 ret 14h 

6a214731 8bd4 mov edx,esp 

6a214733 0f34 sysenter 

6a214735 c3 ret 

0:000> dd 7ffe0300 LI 
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Integrity checks, guard pages, and allocation order randomization 

WINDOWS HEAP 
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Retrospective: Windows Heap 


• Windows Vista heap hardening was very effective [ ] 

— Only one documented exploit that corrupts metadata [9] 

• New attacks have been proposed by researchers 

— Corrupting the HEAP data structure [ ] 

— LFH bucket overwrite [ ] 

— LFH FreeEntryOffset corruption and depth desync [8,121 

• Real-world exploits target app data on the heap [_L0] 

— No heap safeguards exist today for this 


Windows 8 heap architecture 

The general design of the Windows heap is unchanged in Windows 8 


HeapAlloc(heap, flags, size) 


Frontend allocator (LFH) 


Used for sizes < 16KB 


Backend allocator 


Used by frontend and for sizes less than 512K (x86) or 1MB (x64) 


Virtual memory allocator 



Kernel memory manager 









LFH design changes & integrity checks 


Change in Windows 8 

Impact 

LFH is now a bitmap-based allocator 

LinkOffset corruption no longer possible [8] 

Multiple catch-all EH blocks removed 

Exceptions are no longer swallowed 

HEAP handle can no longer be freed 

Prevents attacks that try to corrupt HEAP 
handle state [ 7] 

HEAP CommitRoutine encoded with global key 

Prevents attacks that enable reliable control 
of the CommitRoutine pointer [7] 

Validation of extended block header 

Prevents unintended free of in-use heap 
blocks [Z] 

Busy blocks cannot be allocated 

Prevents various attacks that reallocate an 
in-use block [8.111 

Heap encoding is now enabled in kernel mode 

Better protection of heap entry headers [19] 


Outcome: attacking metadata used by the heap is now even more difficult 
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Guard pages 


• Guard pages are now used to partition the heap 

- Designed to prevent & localize corruption in some cases 

- Touching a guard page results in an exception 


... 

. . PAGE NOACCESS 

Heap memory Gu - ard page 

Heap memory 

... 


• Insertion points for guard pages are constrained 

- Large allocations 

- Heap segments 

- Max-sized LFH subsegments (probabilistic on 32-bit) 
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Allocation order randomization 




Allocation order is now nondeterministic (LFH only) 

- Exploits often rely on surgical heap layout manipulation [JD] 

- Randomization makes heap normalization unreliable 

Windows 7 LFH block allocation behavior 



# 



Maximizing reliability is more challenging 

— Application-specific and vulnerability-specific 

— May require corrupting more data (increasing instability) 

— May require allocating more data (triggering guard pages) 
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DEP, ASLR, SMEP/PXN, NULL dereference protection, and pool integrity 
checks 


WINDOWS KERNEL 
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Retrospective: Windows Kernel 


• Kernel vulnerabilities have been less targeted 

- Relatively few remote kernel exploits exist 

- User mode exploitation is better researched 

• Attack focus is shifting more toward the kernel 

- Interest in sandbox escapes is increasing 

- Local kernel exploitation techniques well-understood 

- New kernel pool attacks have been proposed [13 1 

- Sophisticated remote kernel exploits exist [14, _1] 
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DEP is broadly enabled in the Windows 8 kernel 

Many kernel memory regions were unnecessarily executable in Windows 7 and prior 



x86 (PAE) 

x64 

ARM 

Win7 

Win8 

Win7 

Win8 

Win8 

Paged pool 

X 

X 

NX 

NX 

NX 

Non-paged pool 

X 

X 

X 

X 

X 

Non-paged pool (NX) 

N/A 

NX 

N/A 

NX 

NX 

Session pool 

X 

X 

NX 

NX 

NX 

Image data sections 

X 

X 

NX 

NX 

NX 

Kernel stacks 

NX 

NX 

NX 

NX 

NX 

Idle/DPC/lnitial stacks 

X 

NX 

X 

NX 

NX 

Page table pages 

X 

NX 

X 

NX 

NX 

PFN database 

X 

NX 

X 

NX 

NX 

System cache 

X 

NX 

X 

NX 

NX 

Shared user data 

X 

NX 

X 

NX 

NX 

HAL heap 

X 

NX 

X 

NX 

NX 



Windows 8 introduces 
NonPagedPooINx for 
non-executable non- 
paged pool allocations 
(default on ARM) 


NX HAL heap and 
NonPagedPooINx break 
the assumptions of 
exploits for MS09-050 


= executable MX = non-executable 
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Kernel ASLR improvements 


• Kernel ASLR was first added in Server 2008 RTM 

- 4 bits of entropy for drivers, 5 bits for NTOS/HAL 

- Driver entropy was improved in Windows 7 

• Entropy has been further improved in Windows 8 

- Biasing of kernel segment base 

- NTOS/HAL receive 22 bits (64-bit) and 12 bits (32-bit) 

- Various boot regions also randomized (P0 idle stack) 


31 


Support for SMEP/PXN 

• New processor security feature 

- Prevents supervisor from executing code in user 
pages 

- Most exploits for local kernel EOPs rely on this today 
— Requires Intel Ivy Bridge or ARM with PXN support 

• SMEP/PXN + DEP make exploitation more difficult 

— Strong mitigation for some issues (cvE-2010-2743 from stuxnet) 

- Attackers need to leverage code in kernel images [15] 
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NULL dereference protection 


• Kernel NULL dereferences are a common issue 

- Examples include MS08-025, MS08-061, MS09-001 

• Local exploitation is generally straightforward 

- NULL is part of the user mode address space 

- Kernel currently allows user processes to map NULL page 

• Windows 8 prohibits mapping of the first 64K 

- All kernel NULL dereferences become a DoS (not EoP) 

- NTVDM has been disabled by default as well 

- Enabling NTVDM will disable NULL dereference protection 


33 


Kernel pool integrity checks 


• The kernel pool allocator is similar to the heap 

- Implementation is very different, though 

• New integrity checks block various attacks [ ] 

- Process quota pointer encoding 

- Lookaside, delay free, and pool page cookies 

- Poollndex bounds check 

- Additional safe unlinking checks 
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Other improvements 

• Safe unlinking has been enabled globally 

- Previously only used in the heap and kernel pool 

- Now applies to all usage of LIST_ENTRY, closing known gaps [ 161 

- New "FastFail" mechanism enables rapid & safe process termination 

• Improved entropy for GS and ASLR 

- Use of PRNG seeded by TPM/RDRAND/other sources 

- Hardcoded GS initialization is overridden by the OS 

- Addresses weaknesses described in attack research [ , 181 

• Object manager hardened against reference count overflows 

• Resolved kernel information disclosure via certain system calls [ 22 1 
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ARM, Inbox, Windows 8 style apps, IE 10, the new Office, and other applications 

DEFAULT SETTINGS 
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ARM default settings 


All applicable mitigations are enabled on ARM 


DEP 

On 

ASLR (images) 

On 

ASLR (force relocate) 

N/A (all images are ASLR) 

ASLR (bottom-up) 

On 

ASLR (top-down) 

On 

ASLR (high entropy) 

N/A (not 64-bit) 

SEHOP 

N/A(not needed) 

Heap termination 

On 

Kernel NULL dereference 

On 

Kernel SMEP 

On 


ARM PE images 
/ must opt-in to 
DEPand ASLR 

Kernel will fail 
to load images 
that do not 


Lack of application compatibility concerns enables us to be more aggressive 
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Application default settings 


All applicable mitigations are enabled for Windows 8 Ul style apps 


n r\fn i 1 1 f r- rt 1 1 mrrr fn r 


32 bit (x86) 



64 bit (x64) 


ucTduit bcinrigb tut 

Windows 8 client 









DEP 

On 

On 

On 

Optln 

On 

On 

On 

Optln 

ASLR (images) 

On 

On 

On 

Optln 

On 

On 

On 

Optln 

ASLR (force relocate) 

On 

Optln 

On 

Optln 

On 

Optln 

On 

Optln 

ASLR (bottom-up) 

On 

On 

On 

Optln 

On 

On 

On 

Optln 

ASLR (top-down) 

On 

On 

On 

Optln 

On 

On 

On 

Optln 

ASLR (high entropy) 

N/A 

N/A 

N/A 

N/A 

On 

On 

On 

Optln 

SEHOP 

On 


On 

Optln 

N/A 

N/A 

N/A 

N/A 

Heap termination 

On 

On 

On 

Optln 

On 

On 

On 

On 


Internet Explorer 10 and the new Office also enable all applicable mitigations 
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Enabling opt-in mitigations 

Opt-in methods 

• "MitigationOptions" Image File Execution Option (IFEO) 

• Process creation attribute (via UpdateProcThreadAttribute) 

• SetProcessMitigationPolicy API 

• Linker flag 


Opt-in mitigation 

IFEO 

Proc Attr 

API 

Linker flag 

Bottom-up randomization 

Yes 

Yes 

No 

/DYNAMICBASE (on EXE) 

Top-down randomization 

No 

No 

No 

/DYNAMICBASE (on EXE) 

Bottom-up randomization 
(high entropy) 

Yes 

Yes 

No 

/HIGHENTROPYVA (on EXE) 

ASLR 

No 

No 

No 

/DYNAMICBASE 

Force ASLR 

Yes 

Yes 

Yes 

None 

DEP 

Yes 

Yes 

Yes 

/NXCOMPAT (on EXE) 

SEHOP 

Yes 

Yes 

No 

None* 

Heap termination 

Yes 

Yes 

Yes 

None* 


* EXEs with a subsystem version >= 6.2 will automatically enable these mitigations 
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Expectations for exploits on Windows 8 


• Writing exploits for Windows 8 will be very costly 

- Some vulnerability classes are now entirely mitigated 

- Many attack techniques are now broken or unreliable 

• Attackers will likely focus their attention on 

- Desktop apps that do not enable all applicable mitigations 
— Desktop apps running on previous versions of Windows 

- Refining methods of disclosing address space information 

- Researching new exploitation techniques [ ] 

• We will continue to evolve our mitigation technologies 
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Call to action 


• Upgrade to Windows 8 and IE 10 © 

- 64-bit is best from a mitigations perspective 
— Enable " " for IE 10 

• Software vendors 

— Build your applications with Visual Studio 2012 [ ] 

— Enable new opt-in mitigations 


Driver writers 

- Port your drivers to use gedPooINx 
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Questions? 


Contact us at switech@microsoft.com 


Were you fascinated by the topics discussed in this presentation? 

We are hiring. 

http://www.microsoft-careers.com/go/Trustworthv-Computing-Jobs/194701/ 
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Microsoft • 

Be what's next: 


© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. 
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market 
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. 
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. 
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